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REMARKS 

SUMMARY OF THE AMENDMENTS 

The present application contains thirty-five (35) claims, numbered 35-41, 44-45, 47-50, 52, 
54-73 and 83. 

Claims 1-34, 42, 43, 46, 51, 53 and 74-82 are cancelled. 
Claim 83 is new. 

Claim 35 has been amended to incorporate the feature of former claim 42 and to remove from 
claim 35 a feature that had been previously imported from former claim 43 and which has now 
been placed into new claim 83. 

Claim 45 has been amended to incorporate the features of former claims 46 and 53. 

Claims 47, 54 and 55 have been amended to correct claim dependencies. 

Claim 68 has been amended in a manner similar to claim 35. 

It is believed that no new matter has been added under the present amendment. 

CLAIM REJECTIONS UNDER 35 USC 102 

A. Response to Paragraph 3 

On page 3 of the Office Action, claims 35-42, 44-50 and 52-82 were rejected under 35 U.S.C. 
102(e) as being anticipated by Perlman (U.S. Patent 7,395,549). Claims 42, 46, 53 and 74-82 
have been cancelled, rendering the Examiner's rejection moot. As regards claims 35-41, 44, 
45, 47-50, 52 and 54-73, Applicant respectfully disagrees, and submits that the 
aforementioned claims are not anticipated by Perlman. 
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Claim 35 

Claim 35 is reproduced below for the Examiner's convenience: 
35. An authentication system, comprising: 

an access controller operable to communicate with a client via a first communication 
medium; and 

an authentication server operable to communicate with said client and said access 
controller via a second communication medium and further operable to deliver a first 
key to said client and a second key to said access controller, said second key being 
complementary to said first key such that when said client and said access controller 
are connected, communications therebetween can be encrypted using said keys; and 
wherein said access controller is operable to selectively pass instructions received from 
said client to a computer attached to said access controller if a verification protocol 
utilizing said keys is met; 

wherein said first key is delivered to said client only after said second key has been 
successfully delivered to said access controller. 

It is respectfully submitted that Perlman does not teach or suggest "wherein said first key is 
delivered to said client only after said second key has been successfully delivered to said 
access controller". 

More specifically, Perlman discloses a "method and apparatus for providing a key distribution 
center without storing long-term server secrets" (see Title). Perlman discloses a client (Alice), 
a server (Bob) and a key distribution center (KDC). The KDC "creates a session key, Kab, to 
be used in communications between Alice and Bob. KDC 102 retrieves Bob's temporary 
secret key, TK B , and then creates a "ticket to Bob" by using TKb to encrypt the identifier for 
"Alice" and K AB , and by attaching the key identifier for TK B , KEY ID, in the clear" (col. 6, 
lines 56-61). 
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The KDC then "creates a message containing an identifier "Bob", Kab, and the ticket to Bob, 
and then encrypts the message using the master key for Alice, S A [...] before sending the 
message to client 104 [i.e., Alice]" (coL 6, lines 62-65). 

"Upon receiving this message, client 104 decrypts it using Sa to restore the identifier, "Bob", 
Kab and the ticket to Bob" (col. 6, lines 66-67). 

"[C]lient 104 [i.e., Alice] sends the ticket to Bob to server 106 [i.e., Bob]. Server 106 uses the 
key identifier KEY_ID, to look up the temporary secret key TKb- Server 106 then uses TKb 
to decrypt the ticket to Bob to restore Kab and "Alice". Server 106 [i.e., Bob] subsequently 
uses Kab in communications with client 104 [i.e., Alice]. If client 104 can prove it knows 
Kab, Bob will know client 104 is associated with Alice" (col. 7, lines 6-12). 

Therefore, it should be apparent that the session key, Kab, is necessarily delivered to Alice 
before it can be delivered to Bob, because Alice herself is responsible for delivering Kab to 
Bob directly. Therefore, the session key Kab is delivered to the client, and then it is delivered 
— by the client - to the server. 

More specifically, in Perlman, the KDC encrypts the session key Kab within a "ticket to Bob", 
and then encrypts this "ticket to Bob" together with the session key Kab itself using the master 
key for Alice. Then, in order for Alice to send Bob the "ticket to Bob", Alice must proceed to 
extract the "ticket to Bob" together with the session key by using her master key. It is 
therefore impossible for Bob to retrieve the session key Kab from the "ticket to Bob" 
(received from Alice) without Alice first having retrieved the session key Kab from the 
information sent by the KDC. 

In contrast, and in accordance with the claimed invention, the "first key" is delivered to the 
client only after the "second key 5 ' is successfully delivered to the access controller, following 
which the access controller selectively passes instructions received from the client to an 
attached computer if a verification protocol utilizing the keys is met. This is completely in 
contrast to Perlman' s situation where the session key Kab is necessarily delivered to the client 
before it can be delivered to the server. 
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Li practice, the claimed invention prevents the client from passing instructions to the computer 
via the access controller by using the first key unless the access controller has already had a 
chance to successfully receive the complementary second key. This further enhances security 
of the authentication system, and affords a level of security / sophistication that is not 
provided for in the system of Perlman. 

In view of the foregoing, it is respectfully submitted that Perlman does not teach or suggest 
44 wherein said first key is delivered to said client only after said second key has been 
successfully delivered to said access controller". 

As such, Perlman fails to disclose all the elements of claim 35 and therefore does not 
anticipate claim 35. The Examiner is therefore respectfully requested to withdraw the 
rejection of claim 35. 

Claim 68 

This claim includes language similar to that of claim 35 and therefore it is respectfully 
submitted that claim 35 also includes at least one feature not taught by Perlman and thus is not 
anticipated by Perlman for the same reasons as those set forth above in respect of claim 35. 
The Examiner is therefore respectfully requested to withdraw the rejection of claims 68. 

Claims 36, 37, 38, 39, 41, 44 and 69 

It is noted that each of claims 36, 37, 38, 39, 41, 44 and 69 depends from one of claims 35 and 
68 and, as such, incorporates by reference all the features contained therein, including at least 
one feature shown above as not having been taught by Perlman. It is therefore respectfully 
submitted that claims 36, 37, 38, 39, 41, 44 and 69 are not anticipated by Perlman and the 
Examiner is respectfully requested to withdraw the rejection of claims 36, 37, 38, 39, 41, 44, 
69. 

Claim 40 
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It is noted that claim 40 depends from claim 35 and, as such, incorporates by reference all the 
features contained therein, including at least one feature shown above as not having been 
taught by Perlman. It is therefore respectfully submitted that on this basis alone, claim 40 is 
not anticipated by Perlman. 

In addition, claim 40 includes the feature of "wherein said verification protocol includes a 
generation of a random number by said client, an encryption of said random number by said 
client using said first key, a delivery of said random number and said encrypted random 
number from said client to said access controller, a decryption of said encrypted random 
number using said second key by said access controller, a comparison of said random number 
and said decrypted number, and a decision to pass at least a portion of said instructions if said 
comparison finds a match of said random number with said decrypted number, and a decision 
not to pass said at least a portion of said instructions if no match is found." It is respectfully 
submitted that this feature is also not taught or suggested by Perlman. 

Specifically, nowhere in Perlman is there any mention of "generation of a random number by 
said client , an encryption of said random number by said client using said first key , a delivery 
of said random number and said encrypted random number from said client to said access 
controller ". In Perlman, while Alice / client 104 decrypts the session key Kab and the "ticket 
to Bob" received from the KDC using the master key Sa, Alice / client 104 sends the "ticket to 
Bob" unadulterated. It is then Bob / server 106 that decrypts the "ticket to Bob" using the 
correct temporary key TK B . Thus, it will be seen that Alice / client 104 does not generate a 
random number, nor does Alice / client 104 encrypt such a random number using the session 
key Ka r , nor does Alice / client 104 send Bob / server 106 anything that was encrypted by 
Alice / client 104 . 

Thus, it is respectfully submitted that, in addition to not teaching or suggesting ""wherein said 
first key is delivered to said client only after said second key has been successfully delivered 
to said access controller"", Perlman also does not teach or suggest "wherein said verification 
protocol includes a generation of a random number by said client, an encryption of said 
random number by said client using said first key, a delivery of said random number and said 
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encrypted random number from said client to said access controller, a decryption of said 
encrypted random number using said second key by said access controller, a comparison of 
said random number and said decrypted number, and a decision to pass at least a portion of 
said instructions if said comparison finds a match of said random number with said decrypted 
number, and a decision not to pass said at least a portion of said instructions if no match is 
found." 

As such, Perlman fails to disclose all the elements of claim 40 and therefore does not 
anticipate claim 40. The Examiner is therefore respectfully requested to withdraw the 
rejection of claim 40. 

Claim 45 

Claim 45 is reproduced below for the Examiner's convenience: 

45. An access controller for intermediating communications between an interface and a 
computer and operable to store a second key complementary to a first key; said access 
controller operable to communicate with a client via said interface; said client operable 
to store said first key and to receive instructions from a user; said access controller 
operable to selectively pass said instructions to said computer if a verification protocol 
utilizing said keys is met; wherein said verification protocol includes a generation of a 
random number by said client, an encryption of said random number by said client 
using said first key, a delivery of said random number and said encrypted random 
number from said client to said access controller, a decryption of said encrypted 
random number using said second key by said access controller, a comparison of said 
random number and said decrypted number, and a decision to pass at least a portion of 
said instructions if said comparison finds a match of said random number with said 
decrypted number, and a decision not to pass said at least a portion of said instructions 
if no match is found; wherein said access controller is operable to obtain said second 
key from an authentication server and said client is operable to obtain said first key 
from said authentication server; wherein said first key is obtained by said client only 
after said second key has been successfully obtained by said access controller. 
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It is respectfully submitted that Perlman does not teach or suggest a verification protocol that 
includes "a generation of a random number by said client, an encryption of said random 
number by said client using said first key, a delivery of said random number and said 
encrypted random number from said client to said access controller, a decryption of said 
encrypted random number using said second key by said access controller, a comparison of 
said random number and said decrypted number, and a decision to pass at least a portion of 
said instructions if said comparison finds a match of said random number with said decrypted 
number, and a decision not to pass said at least a portion of said instructions if no match is 
found" and "wherein said first key is obtained by said client only after said second key has 
been successfully obtained by said access controller." 

More specifically, Perlman discloses a "method and apparatus for providing a key distribution 
center without storing long-term server secrets" (see Title). Perlman discloses a client (Alice), 
a server (Bob) and a key distribution center (KDC). The KDC "creates a session key, Kab, to 
be used in communications between Alice and Bob. KDC 102 retrieves Bob's temporary 
secret key, TK B , and then creates a "ticket to Bob" by using TK B to encrypt the identifier for 
"Alice" and Kab, and by attaching the key identifier for TK B , KEY_ID, in the clear" (col. 6, 
lines 56-61). 

The KDC then "creates a message containing an identifier "Bob", Kab, and the ticket to Bob, 
and then encrypts the message using the master key for Alice, S A [-..] before sending the 
message to client 104 [i.e., Alice]" (col. 6, lines 62-65). 

"Upon receiving this message, client 104 decrypts it using S A to restore the identifier, "Bob", 
Kab and the ticket to Bob" (col. 6, lines 66-67). 

"[C]lient 104 [i.e., Alice] sends the ticket to Bob to server 106 [i.e., Bob]. Server 106 uses the 
key identifier KEY ID, to look up the temporary secret key TK B . Server 106 then uses TK B 
to decrypt the ticket to Bob to restore Kab and "Alice". Server 106 [i.e., Bob] subsequently 
uses Kab in communications with client 104 [i.e., Alice]. If client 104 can prove it knows 
Kab, Bob will know client 104 is associated with Alice" (col. 7, lines 6-12). 
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Therefore, it should be apparent that the session key, Kab, is necessarily obtained by Alice 
before it can be obtained by Bob, because Alice herself is responsible for delivering Kab to 
Bob directly. Therefore, the session key is obtained by the client, and then it is obtained - 
thanks to the client - by the server. 

More specifically, in Perlman, the KDC encrypts the session key within a "ticket to Bob", and 
then encrypts this "ticket to Bob" together with the session key itself using the master key for 
Alice. Then, in order for Alice to send Bob the "ticket to Bob", Alice must proceed to extract 
the "ticket to Bob" together with the session key by using her master key. It is therefore 
impossible for Bob to retrieve the session key from the "ticket to Bob" (received from Alice) 
without Alice first having retrieved the session key from the information sent by the KDC. 

In contrast, and in accordance with the claimed invention, the "first key" is obtained by the 
client only after the "second key" is successfully obtained by the access controller, following 
which the access controller selectively passes instructions received from the client to an 
attached computer if a verification protocol utilizing the keys is met. This is completely in 
contrast to Perlman's situation where the session key is necessarily delivered to the client 
before it can then be delivered to the server. 

In practice, the claimed invention prevents the client from passing instructions to the computer 
via the access controller by using the first key unless the access controller has already had a 
chance to successfully receive the complementary second key. This further enhances security 
of the authentication system, and affords a level of security / sophistication that is not 
provided for in the system of Perlman. 

Moreover, nowhere in Perlman is there any mention of "generation of a random number by 
said clien t, an encryption of said random number by said client using said first key, a delivery 
of said random number and said encrypted random number from said client to said access 
controller ". In Perlman, while Alice / client 104 decrypts the session key Kab and the "ticket 
to Bob" received from the KDC using the master key Sa, Alice / client 104 sends the "ticket to 
Bob" unadulterated. It is then Bob / server 106 that decrypts the "ticket to Bob" using the 
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correct temporary key TK B . Thus, it will be seen that Alice / client 104 does not generate a 
random number, nor does Alice / client 1 04 encrypt such a random number using the session 
key Ka^, nor does Alice / client 104 send Bob / server 106 anything that was encrypted by 
Alice / client 104 . 

Thus, it is respectfully submitted that Perlman does not teach or suggest a verification protocol 
that includes "a generation of a random number by said client, an encryption of said random 
number by said client using said first key, a delivery of said random number and said 
encrypted random number from said client to said access controller, a decryption of said 
encrypted random number using said second key by said access controller, a comparison of 
said random number and said decrypted number, and a decision to pass at least a portion of 
said instructions if said comparison finds a match of said random number with said decrypted 
number, and a decision not to pass said at least a portion of said instructions if no match is 
found" and "wherein said first key is obtained by said client only after said second key has 
been successfully obtained by said access controller." 

As such, Perlman fails to disclose all the elements of claim 45 and therefore does not 
anticipate claim 45. The Examiner is therefore respectfully requested to withdraw the 
rejection of claim 45. 

Claims 47-50, 52, 54 and 55 

It is noted that claims 47-50, 51, 54 and 55 depend from claim 45 and, as such, incorporate by 
reference all the features contained therein, including at least one feature shown above as not 
having been taught by Perlman. It is therefore respectfully submitted that claims 47-50, 51, 54 
and 55 are not anticipated by Perlman and the Examiner is respectfully requested to withdraw 
the rejection of claims 47-50, 51, 54 and 55. 

Claim 67 

Claim 67 is reproduced below for the Examiner's convenience: 
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67. A method of securing access between a client and a computer having an access 

controller intermediate said client and said computer, said method comprising: 

receiving an instruction at said client destined for said computer; 

generating a random number by said client; 

encrypting said random number by said client using a first key; 

delivering said random number, said encrypted random number and said instruction to 
said access controller; 

decrypting said encrypted random number using a second key by said access 
controller, said second key complementary to said first key; 
comparing said random number and said decrypted number; 

passing at least a portion of said instruction to said computer if said comparison finds a 
match of said random number with said decrypted number; and, 
discarding said at least a portion if no match is found. 

It is respectfully submitted that Perlman does not teach or suggest "generating a random 
number by said client; encrypting said random number by said client using a first key; 
delivering said random number, said encrypted random number and said instruction to said 
access controller; decrypting said encrypted random number using a second key by said access 
controller, said second key complementary to said first key; comparing said random number 
and said decrypted number; passing at least a portion of said instruction to said computer if 
said comparison finds a match of said random number with said decrypted number; and, 
discarding said at least a portion if no match is found." 

More specifically, Perlman discloses a "method and apparatus for providing a key distribution 
center without storing long-term server secrets" (see Title). Perlman discloses a client (Alice), 
a server (Bob) and a key distribution center (KDC). The KDC "creates a session key, Kab, to 
be used in communications between Alice and Bob. KDC 102 retrieves Bob's temporary 
secret key, TK B , and then creates a "ticket to Bob" by using TK B to encrypt the identifier for 
"Alice" and Kab, and by attaching the key identifier for TK B? KEY_ID, in the clear" (col. 6, 
lines 56-61). 
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The KDC then "creates a message containing an identifier "Bob", Kab, and the ticket to Bob, 
and then encrypts the message using the master key for Alice, S A [...] before sending the 
message to client 104 [i.e., Alice]" (col. 6, lines 62-65). 

"Upon receiving this message, client 104 decrypts it using Sa to restore the identifier, "Bob", 
Kab and the ticket to Bob" (col. 6, lines 66-67). 

"[C]lient 104 [i.e., Alice] sends the ticket to Bob to server 106 [i.e., Bob]. Server 106 uses the 
key identifier KEYID, to look up the temporary secret key TK B . Server 106 then uses TK B 
to decrypt the ticket to Bob to restore Kab and "Alice". Server 106 [i.e., Bob] subsequently 
uses Kab in communications with client 104 [i.e., Alice]. If client 104 can prove it knows 
Kab, Bob will know client 104 is associated with Alice" (col. 7, lines 6-12). 

Therefore, it should be apparent that Alice's role is to decrypt information received from the 
KDC and to merely forward the decrypted information (which is still encrypted to a certain 
degree) to Bob. However, Alice's role is not to perform encryption of random numbers for 
the purposes of legitimizing itself to Bob. In particular, nowhere in Perlman is there any 
mention of "generation of a random number by said client, an encryption of said random 
number by said client using said first key, a delivery of said random number and said 
encrypted random number from said client to said access controller." 

Thus, it is respectfully submitted that Perlman does not teach or suggest "generating a random 
number by said client; encrypting said random number by said client using a first key; 
delivering said random number, said encrypted random number and said instruction to said 
access controller; decrypting said encrypted random number using a second key by said access 
controller, said second key complementary to said first key; comparing said random number 
and said decrypted number; passing at least a portion of said instruction to said computer if 
said comparison finds a match of said random number with said decrypted number; and, 
discarding said at least a portion if no match is found". 
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As such, Perlman fails to disclose all the elements of claim 67 and therefore does not 
anticipate claim 67. The Examiner is therefore respectfully requested to withdraw the 
rejection of claim 67. 

Claims 56-66. 70 and 71 

On page 6 of the Office Action, the Examiner states that claims "45-50, 52-55, 58-69 and 74- 
82 do not teach or defined any new limitations beyond the claims above, therefore, they are 
rejected for similar reasons." With respect, the Examiner's statement is incorrect. 

It is noted that the Examiner made similar remarks in previous Office Actions, which have 
been similarly refuted by Applicant in previous responses. At present, the Examiner is 
respectfully requested to note that claim 56 includes the following emphasized features that 
are not present in claims 35-40, 41 or 44: 

56. In an authentication server, a method of securing access between a client having 
temporary connection to a computer via an access controller, said access controller for 
selectively passing instructions received from said client to said computer if a 
verification protocol utilizing a set of keys is met, said method comprising: 
receiving a request from said access controller for an updated first key ; 
authenticating said request; 

determining said updated first key and a second key corresponding to said 
updated first key : and 

delivering said updated first key to said access controller . 

The Examiner is therefore respectfully requested to allow claim 56 (as well as claims 57-66 
dependent thereon and claims 70 and 71 containing similar features), or to provide a complete 
examination report in which all features of the above claims are fully addressed. 

Claims 72 and 73 
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On page 6 of the Office Action, the Examiner states that claims "45-50, 52-55, 58-69 and 74- 
82 do not teach or defined any new limitations beyond the claims above, therefore, they are 
rejected for similar reasons." With respect, the Examiner's statement is incorrect. 

It is noted that the Examiner made similar remarks in previous Office Actions, which have 
been similarly refuted by Applicant in previous responses. At present, the Examiner is 
respectfully requested to note that claim 56 includes the following emphasized features that 
are not present in claims 35-40, 41 or 44: 

72. In an access controller for selectively passing instructions between a client and a 
computer if a verification protocol is met, a method of expiring said verification 
protocol , comprising: 

determining if a first preset period of time since said client disconnected from 
said access controller has elapsed ; 

determining if a second preset period of time since said verification protocol was 
updated has elapsed ; and, 

expiring said verification protocol by refusing to pass said instructions if either of 
said preset periods of time have elapsed . 

The Examiner is therefore respectfully requested to allow claim 72 (as well as claim 73 
dependent thereon), or to provide a complete examination report in which all features of the 
above claims are fully addressed. 

COMMENTS ON NEW CLAIM 

It is noted that new claim 83 depends from claim 35 and, as such, incorporates by reference all 
the features contained therein. Thus, it is respectfully submitted that new claim 83 is in 
allowable form. 
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CONCLUSION 



In view of the foregoing, Applicant is of the view that claims 35-41, 44-45, 47-50, 52, 54-73 
and 83 are in allowable form. Favourable reconsideration and withdrawal of all rejections is 
respectfully requested. Early allowance of the Application is earnestly solicited. 

If the application is not considered to be in full condition for allowance, for any reason, the 
Applicant respectfully requests the constructive assistance and suggestions of the Examiner 
for placing the application in allowable condition as soon as possible and without the need for 
further proceedings. 
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